1. Field of the Invention
The present invention relates to the field of telecommunications. More particularly, the present invention relates to a method and a system for routing Internet Protocol (IP) multicast traffic over Asynchronous Transfer Mode (ATM) networks.
2. Description of the Related Art
Many applications used on the Internet have multiple sources, or senders, and hosts, or receivers, that participate, or interact, with each other. Previously, conventional unicast techniques were used for sending the same data packet to each host of a multicast group over a circuit that was specifically established between a source and the host. A conventional unicast approach for multicasting traffic, however, is wasteful in terms of both bandwidth and circuit resources.
To overcome the drawbacks of using unicast techniques for multicast traffic, techniques and protocols have been developed so that a multicast data packet is sent along a predetermined route of routers, or switches, and replicated at a point closest to a destination host, thereby reducing the amount of multicast traffic. For example, a number of routing protocols have been developed for creating distribution routes between a source and the hosts of a multicast group. Routers and end stations have become xe2x80x9cmulticast awarexe2x80x9d by using multicast protocols such as the Distance Vector Multicast Routing Protocol (DVMRP), the Multicast Open Shortest Path First (MOSPF) protocol and Protocol-Independent Multicast (PIM).
The DVMRP protocol is widely used in the Multicast Backbone (MBONE) and generates a separate distribution tree for each respective source and destination host group. The distribution tree, also referred to as a spanning tree, provides the shortest path from a source to each host in a multicast group. A spanning tree is constructed for a multicast group by the source initially broadcasting, or sending, a message to an adjacent router that is propagated to all other routers in the network so that the message reaches each participating host. The message effectively registers the multicast group with reach router receiving the message. If no members for a registered multicast group are connected to a particular router, the router sends a pruning message to the previously adjacent router so that the router sending the pruning message is removed from the spanning tree. As a result, the spanning tree that is eventually generated provides the shortest path between the source and every host in the network. Periodically, the broadcast and pruning operations are performed for updating the spanning tree. While the DVMRP protocol works well for a densely-distributed multicast group, the overhead processing associated with message broadcasts and maintenance of state information can become expensive for a sparse distribution of hosts across a wide area network.
The MOSPF protocol is a multicast routing protocol that is built on top of the OSPF protocol, thereby providing the ability to create multicast trees having an OSPF routing domain. Each MOSPF router receives information about hosts that are interested in a particular multicast group through an Internet Group Management Protocol (IGMP) registration process. Consequently, all routers in the OSPF domain contain information relating to the complete topology of the network and can construct the optimum path between a source and any other host in the domain. Nevertheless, multicast trees generated using the MOSPF protocol cannot span OSPF domain boundaries. Further, the MOSPF protocol generates significant amounts of overhead routing information that is continuously exchanged between routers in the network so multicast trees spanning large domains do not scale well.
The PIM protocol, developed by the Internet Engineering Task Force (IETF), addresses problems associated with crossing domain boundaries, and is independent of any underlying unicast protocol. The PIM protocol includes a dense mode and a sparse mode. Dense-mode PIM (PIM-DM) is suitable for environments in which many of the different domains, or subnets, contain at least one host participating in a multicast group and in which network bandwidth is not critical. Unlike the DVMRP protocol, the PIM-DM protocol uses a simple technique of sending a data packet arriving at a router to all adjacent downstream routers. The adjacent downstream routers, in turn, send the packet to their respectively adjacent routers. The routing tree is pruned as each router determines whether there are any hosts participating in the multicast group that are connected to the router.
When the hosts in a network are sparsely distributed, the overhead associated with PIM-DM of flooding information through a network becomes too significant and the PIM-SM protocol is used. In PIM-SM, a host that is interested in joining a particular multicast group is responsible for initiating a join operation to join the multicast routing tree associated with the multicast group. A join request is sent from the interested host towards the source of the multicast tree. The join request is propagated toward the source until the request encounters a router that already has a host participating in the desired multicast group. The routing tree is then updated to include all of the routers between the host initiating the join operation and the router where the propagation of the join request terminates.
Deployment of multicast protocols on routers has proceeded at a steady pace. Nevertheless, there are still so-called xe2x80x9cislandsxe2x80x9d of routers that are multicast-aware that are separated from other islands of multicast-aware routers. FIG. 1 is a schematic block diagram showing an exemplary conventional MBONE network 10 having a plurality of multicast-aware routers 11 and unicast routers 12. A multicast-aware router or a group of multicast-aware routers that are separated from other multicast-aware routers 11 by one or more unicast routers 12 are referred to as islands. In order to transport multicast traffic between multicast-aware routers 11 across one or more unicast routers 12, a technique known as xe2x80x9cmulticast tunnelingxe2x80x9d is used. That is, a multicast-aware router 11 encapsulates multicast traffic inside a unicast packet. The encapsulated multicast traffic is then sent, or tunneled, across a portion of the network having unicast routers.
A number of other protocols are under development by the IETF that run on top of conventional routing protocols and which provide the ability for an application to reserve resources in a network so that a specified Quality of Service (QoS) can be achieved. Examples of these particular protocols are the Resource Reservation Protocol (RSVP) and the Real Time Protocol (RTP).
The ATM Forum has developed a specification, known as the LAN Emulation specification (LANE), that permits Legacy LANs- and ATM-connected hosts to communicate across an ATM link without changes to existing applications or software. The LANE specification defines an Emulated Local Area Network (ELAN) environment in which, from the perspective of a legacy application, an ATM network looks appears to be a LAN segment. There are three special entitles in a LANE environment that are referred to as a LAN Emulation Server (LES), a Broadcast Unknown Server (BUS) and an LAN Emulation Configuration Server (LECS). The LES registers and resolves ATM addressing by labeling each end station with a Medium Access Control (MAC) layer and an ATM address. The address mapping is used by an ingress LAN Emulation Client (LEC) for setting up a cut-through path to an egress LEC. The BUS is used for distributing broadcast and multicast traffic within the LANE environment.
When a LEC sends a multicast or broadcast packet to other multicast group members within an ELAN, the packet is sent to a BUS. The BUS forwards the packet to all the other LECs within the ELAN environment on a point-to-multipoint virtual channel connection (VCC). An alternative entity to a BUS is a Special Multicast Server (SMS). A LEC wishing to receive data for a multicast address registers with an SMS and is added to the desired multicast group. Traffic received on the SMS for a particular multicast group is forwarded only on the point-to-multipoint circuit for the multicast group, thus preventing other LECs within the ELAN environment from receiving traffic in which they have no interest. While the LANE specification operates with legacy LANs- and ATM-connected hosts, the LANE specification applies only to a single ELAN environment, which, by definition, is a single subnet of an ATM network. A multicast solution in which an ELAN spans different subnet boundaries is not defined under the LANE specification.
Multiprotocol over ATM (MPOA) is a standard that is built on top of the LANE and the NHRP protocols. The MPOA protocol uses LANE when traffic is confined within a single subnet, but uses the NHRP protocol when traffic crosses subnet boundaries. FIG. 2 is a schematic block diagram showing a conventional MPOA implementation traversing a plurality of subnets 21. As data initially begins to flow from a source 22 to a destination host 23, the data follows a default data path 24 through each subnet 21 using ELAN techniques. At each boundary router 25, the packet is reassembled and Level 3 processing occurs so that the packet can be successfully forwarded to the next subnet 21. While the data packet is traversing default data path 24, a NHRP request is generated for determining the ATM address of destination host 23. Once the ATM destination address information is available, source 22 can set up a direct unicast connection 26 to destination host 23 using NHRP protocol concepts, thereby bypassing all router hops and expensive Level 3 processing.
For each of the conventional IP multicast routing protocols, such as DVMRP, MOSPF, PIM, LANE and MPOA, a considerable amount of state information must be exchanged between routers participating in a multicast. Consequently, overhead traffic, including xe2x80x9cjoinxe2x80x9d and xe2x80x9cprunexe2x80x9d messages, becomes a significant portion of the multicast traffic as a multicast group grows in size. Further, for the DVMRP, MOSPF and PIM protocols, a multicast data packet flows hop-by-hop from one multicast router to the next until the packet reaches its destination. At each hop, Level 3 processing occurs, thereby causing considerable segmentation and reassembly overhead processing. When the LANE and MPOA protocols are used, multicast traffic is confined to an ELAN. Consequently, a host desiring to join a multicast group, but not belonging to a particular ELAN is unable to participate in the multicast session without first becoming a member of the ELAN. This poses a significant problem for dynamically altering membership to a multicast group because a LAN Emulation client (host) can belong to only one ELAN at a time.
What is needed is a way to forward multicast traffic across an ATM network that does not incur significant overhead processing expenses, that scales well, that reduces the number of router hops experienced by a multicast packet when forwarded across the ATM network, and makes efficient use of network resources and network bandwidth.
The present invention provides multicast traffic forwarding across an ATM network that does not incur significant overhead processing expenses, scales well, reduces the number of router hops experienced by a multicast packet when forwarded across an ATM network, and makes efficient use of network resources and network bandwidth. The advantages of the present invention are provided by a method and a system for forwarding multicast data packets across a plurality of telecommunications subnets interconnected by routers in which a data packet is received within a subnet of the plurality of telecommunications subnets. When the data packet is a multicast data packet, a multicast IP address for the multicast data packet is determined. A multicast forwarding database is accessed for determining a LAN Emulation Client associated with the multicast IP address, and a Broadcast Unknown Server associated with the multicast IP address for the multicast data packet is determined. The multicast data packet is sent to the Broadcast Unknown Server associated with the multicast IP address for the multicast data packet through the LAN Emulation Client using a point-to-point connection. The Broadcast Unknown Server sends the multicast data packet inter-subnet to each router associated with the multicast IP address for the multicast data packet using a point-to-multipoint connection, with at least one multicast host being connected to a subnet that is different from the subnet in which the multicast data packet was received. When the data packet is not a multicast data packet, the data packet is sent to a destination address for the data packet using intra-subnet techniques.